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Beschreibung 

Betriebsverfahren fur einen Server und hiermit korrespondie- 
rende Gegenst&nde 

5 

Die vorliegende Erfindung betrifft ein Betriebsverfahren fur 
einen Server , der mit einem Client kommuniziert , wobei der 
Server, wenn ihm vom Client eine Anforderung fur eine Seite 
ubermittelt wird, die angeforderte Seite an den Client liber- 
ie mittelt. 

Die vorliegende Erfindung betrifft ferner einen DatentrSger 
mit einem auf dem Datentrager gespeicherten Computerprogramm 
zur Durchfuhrung eines derartigen Betriebsverf ahrens . 

15 

Die vorliegende Erfindung betrifft weiterhin einen Server mit 
einem Massenspeicher, in dem ein Computerprogramm hinterlegt 
ist, so dass bei Aufruf des Computerprogramms von dem Server 
Rechner ein derartiges Betriebsverfahren ausfuhrbar ist. 

20 

Derartige Verfahren, Computerprogramme und Server sind allge- 
mein bekannt. Sie werden insbesondere bei Web-Anwendungen, 
z.B. bei Internet- und Intranet-Anwendungen, eingesetzt. 

25 Web-Anwendungen sind relativ anonym, Der Server und der 

Client wissen in aller Regel sehr wenig voneinander. Insbe- 
sondere ist es dem Server in aller Regel nicht moglich, an- 
hand einer Anforderung fur eine Seite ohne Weiteres zu ermit- 
teln, von welchem Client ihm diese Anforderung tibermittelt 

30 wurde und aus welchem Zustand des Clients heraus die Anforde- 
rung erfolgte. Jede an der Server gerichtete Anforderung muss 
daher in der Regel eine vollstandige Information uber den an- 
fordernden Client und tiber die angeforderte Seite enthalten. 

35 Urn innerhalb einer Sitzung zwischen Server und Client (= Ses- 
sion) serverseitig dennoch gewisse Voreinstellungen (z.B. ei- 
ne Auswahl einer Sprache, die im Folgenden stets benutzt wer- 
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den soil) treffen zu k6nnen, ist es insbesondere bekannt, 
dass der Client sich zu Beginn der Sitzung beim Server anmel- 
det und dieser zusatzlich zur angef orderten Seite eine An- 
hangseldatei (ein sogenanntes Cookie) an den Client abermit- 
telt. Die Anhangseldatei wird vom Client jeder an diesen Ser- 
ver gerichteten Anforderung beigefugt. Sie wird also vom 
Client an den Server zurtick Ubermittelt . Die Anhangseldatei 
ist dabei spezifisch fur den Server. Sie wird vom Client also 
bei jeder an diesen Server gerichteten Anforderung mit an den 
Server ubermittelt. Die Obermittlung der Anhangseldatei er- 
folgt so lange, bis entweder die Anhangseldatei auf Seiten 
des Clients gelCscht wird oder vom Server eine neue Anhang- 
seldatei an den Client ubermittelt wird, so dass die bisheri- 
ge Anhangseldatei tiberschrieben wird. 

Die Voreinstellungen, die getroffen werden sollen, k6nnen in 
der Anhangseldatei selbst enthalten sein. Alternativ kann die 
Anhangseldatei auch einen Link auf einen Speicherbereich im 
Server enthalten. In diesem Fall sind die Voreinstellungen 
als solche im Server gespeichert, wahrend sie im erstgenann- 
ten Fall im Client gespeichert sind. 

Der Zustand der Sitzung ist iiblicherweise an die Sitzung im 
Sinne der Existenz des korrespondierenden clientseitigen Kom- 
munikationsprogramms, z.B. eines Internetbrowsers wie dem In- 
ternetexplorer von Microsoft , gebunden. Die Vorgehensweise 
des Standes der Technik funktioniert daher problemlos, solan- 
ge auf Seiten des Clients der Kommunikationsprozess erhalten 
bleibt und die Kommunikation mit dem Server uber ein einziges 
Fenster erfolgt 

Es ist aber allgemein bekannt, dass es moglich ist, in ein 
und demselben Internetbrowser parallel mehrere Fenster zu 
nutzen. Die Erzeugung mehrerer Fenster kann z. B. beim Inter- 
netexplorer von Microsoft durch Betatigen der Tastenkombina- 
tion "Steuerung N" oder durch wahlen der Option "Offnen in 
neuem Fenster " erfolgen. Auch in diesem Fall bereitet der 
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Standes der Technik noch keine Probleme, wenn auf Seiten des 
Clients zwar mehrere Fenster genutzt werden, in alien Fens- 
tern aber stets dieselben Voreinstellungen benutzt werden. 

Die Vorgehensweise des Standes der Technik versagt aber, wenn 
auf Seiten des Clients mit mehreren Fenstern gearbeitet wird 
und in den Fenstern voneinander verschiedene Voreinstellungen 
getroffen werden sollen. Denn wie bereits erwahnt, ist der 
Server nicht in der Lage, zu unterscheiden, von welchem der 
Fenster die jeweilige Anforderung an ihn tibermittelt wurde. 
Dabei hilft auch die Verwendung der Anhangseldatei nicht wei- 
ter. Denn ein neues Fenster auf Seiten des Clients ist eben 
nur ein eigenes Fenster, nicht aber ein eigener Prozess. So- 
mit benutzen die Fenster die gleichen Anhangseldateien. 

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Be- 
triebsverfahren flir einen Server, ein hiermit korrespondie- 
rendes Computerprogramm und den entsprechenden Server zu 
schaffen, mittels derer derartige Voreinstellungen individu- 
ell fttr jedes clientseitige Fenster vorgenommen werden kon- 
nen. 

Die Aufgabe wird durch ein Betriebsverf ahren fur einen Ser- 
ver, der mit einem Client kommuniziert , dadurch geldst, 
25 - dass der Server, wenn ihm vom Client eine Anforderung fur 
eine Seite tibermittelt wird, die angeforderte Seite an den 
Client ubermittelt, 

- dass der Server der Seite Identif izierungsdaten derart bei- 
fiigt, dass die Identif izierungsdaten bei einer weiteren An- 

30 forderung fur eine Seite vom Client dann und nur dann an 

den Server zurtick ubermittelt werden, wenn die Anforderung 
auf Seiten des Clients von dieser Ubermittlung der Seite 
ausgeht, 

- dass die Identif izierungsdaten zumindest einen fur die 

35 Ubermittlung der Seite spezifischen Obermittlungsidentif i- 
zierer umfassen, 
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- class der Server die von ihm tibermittelten Identif izierungs- 
daten abspeichert, 

- dass der Server bei Erhalt der weiteren Anforderung den von 
ihm neu tibermittelten Obermittlungsidentif izierer anstelle 
des zurtick tibermittelten Obermittlungsidentif izierers ab- 
speichert, wenn der zuruck tibermittelte Obermitt lungs iden- 
tifizierer mit einem abspeicherten Obermittlungsidentif i- 
zierer abereinstimmt , und 

- dass der Server bei Erhalt der weiteren Anforderung den von 
ihm neu tibermittelten Obermittlungsidentif izierer zusStz- 
lich zum zuruck tibermittelten Obermittlungsidentif izierer 
abspeichert, wenn der zurtick tibermittelte Obermittlungsi- 
dentif izierer mit keinem zuvor abspeicherten Obermittlung- 
sidentif izierer ubereinstimmt - 

Durch diese Vorgehensweise kann der Server n^mlich zwar noch 
nicht erkennen, wenn auf Seiten des Clients ein zweites Fens- 
ter gedf fnet wird (dazu spater) . Er kann aber erkennen, wenn 
ihm vom Client "veraltete" Identif izierungsdaten tibermittelt 
werden. Anhand dieses Umstands, namlich dass die Identif izie- 
rungsdaten bereits veraltet bzw. tiberholt sind, kann er daher 
erkennen, dass ein zweites Fenster ge6ffnet worden sein muss. 
Ab dem Zeitpunkt dieser Erkenntnis ist der Server somit in 
der Lage, dieses zweite Fenster getrennt vom ersten Fenster 
zu verwalten. 

Der Obermittlungsidentifizierer kann im einfachsten Fall eine 
laufende Nummer oder dergleichen sein. Vorzugsweise aber ist 
der Obermittlungsidentifizierer ein weltweit einmaliger Iden- 
tif ikator. Beispielsweise kann der Obermittlungsidentifizie- 
rer ein sogenannter GUID sein. Ein GUID (global universal 
identifier) wird auf die - in der Regel auf eine Millisekunde 
genaue - Zeit des Servers sowie Identif ikationsdaten des Ser- 
vers gebildet, beispielsweise eine nur einmal vergebene Iden- 
tif ikationsnummer der Netzwerkkarte des Servers oder des Pro- 
zessors des Servers. 
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Durch die erf indungsgemaJSe Vorgehensweise ist es beispiels- 
weise moglich, dass den Identif izierungsdaten Selektionsdaten 
zugeordnet sind und dass im Falle der Obereinstimmung des zu- 
rtick iibermittelten Obermittlungsidentif izierers mit einem der 
abgespeicherten Obermittlungsidentif izierer die vom Server 
auf Grund der weiteren Anforderung neu an den Client Ubermit- 
telte Seite von den dem iibereinstimmenden Obermittlungsiden- 
tifizierer zugeordneten Selektionsdaten abhangt. 

Im Falle der Obereinstimmung des zuruck ubermittelten Ober- 
mittlungsidentif izierers mit keinem der abgespeicherten 0ber~ 
mittlungsidentif izierer sind verschiedene Vorgehensweisen 
mOglich. So kann beispielsweise eine vorbestimmte Startseite 
an den Client ubermittelt werden. Vorzugsweise aber hangt die 
vom Server auf Grund der weiteren Anforderung neu an den 
Client ubermittelte Seite von den einem der abgespeicherten 
Obermittlungsidentif izierer zugeordneten Selektionsdaten ab. 
Diese Selektionsdaten ordnet der Server dann selbstverstand- 
lich auch dem zusatzlich abgespeicherten Obermittlungsidenti- 
f izierer zu. 

Vorzugsweise umfassen die Identif izierungsdaten auch einen 
Fensteridentif izierer. Im Falle der Obereinstimmung des zu- 
rack Ubermittelten Obermittlungsidentif izierer mit einem der 
abgespeicherten Obermittlungsidentif izierer wird in diesem 
Fall der Fensteridentif izierer beibehalten. Wenn hingegen der 
zuruck ubermittelte Obermittlungsidentif izierer mit keinem 
der abgespeicherten Obermittlungsidentif izierer uberein- 
stimmt f ordnet der Server dem zusatzlich abgespeicherten 
Obermittlungsidentif izierer einen neuen Fensteridentif izierer 
zu. 

Auf Grund dieser Vorgehensweise ist insbesondere eine effi- 
ziente Verwaltung von mehr als zwei clientseitigen Fenstern 
mSglich. Denn auf Grund dieser Vorgehensweise ist fur den 
Server erkennbar, welches Fenster clientseitig dupliziert 
wurde . 
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Auf Grund dieser Vorgehensweise ist es weiterhin mOglich, 
dass im Falle der Ubereinstimmung des zurtick tibermittelten 
Ubermittlungsidentifizierers mit keinem der abgespeicherten 
Ubermittlungsidentifizierer die vom Server auf Grund einer 
weiteren Anforderung neu an den client tibermittelte Seite von 
den Selektionsdaten abhSngt, die demjenigen der abgespeicher- 
ten Ubermittlungsidentifizierer zugeordnet sind, dessen Fen- 
steridentif izierer mit dem zurtick tibermittelten Fensteriden- 
tifizierer tibereinstimmt . 

Der neue Fensteridentif izierer kann - analog zum Ubermitt- 
lungsidentifizierer - im einfachsten Fall wieder eine laufen- 
de Nummer sein. Vorzugsweise ist aber auch er als GUID ausge- 
bildet. Dabei kann er alternativ als eigenstandig generierter 
GUID ausgebildet sein oder mit dem unmittelbar zuvor gene- 
rierten Ubermittlungsidentif izierer identisch sein. 

Der Server verwaltet die Identif izierungsdaten vorzugsweise 
in Form einer Tabelle, die pro Zeile die Eintrage Fenster- 
identif izierer, Ubermittlungsidentifizierer und Selektionsda- 
ten enthalt. Anstelle der Selektionsdaten selbst kann in der 
Tabelle selbstverstandlich auch ein Verweis (= Pointer) auf 
die Selektionsdaten gespeichert sein. 

Die Prtifungsreihenfolge (erst die Ubermittlungsidentifizierer 
oder erst die Fensteridentif izierer) ist prinzipiell in das 
Belieben des Fachmanns gestellt. Vorzugsweise wird aber zu- 
erst der Fensteridentif izierer tiberprtift und dann der fur 
diesen Fensteridentif izierer gespeicherte Ubermittlungsiden- 
tifizierer. Denn der vom Client zurtick tibermittelte Fenster- 
identif izierer ist stets abgespeichert . Der vom Client zurtick 
tibermittelte Ubermittlungsidentifizierer hingegen konnte be- 
reits tiberschrieben sein. 

Bei Web-Anwendungen sind im Wesentlichen zwei Arten der An- 
forderungstibermittlung bekannt, namlich die sogenannten Post- 
Requests und die sogenannten Get-Requests. 
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Post-Requests beruhen auf dem Prinzip, dass der Client Einga- 
befelder der Seite ausftillt und dann die ausgefullten Einga- 
bef elder vom Client an den Server zuruck tibermittelt werden. 
Bei Post-Requests werden dabei vom Client stets alle Eingabe- 
5 f elder an den Server zuruck Ubermittelt . Die ubermittelten 
Daten enthalten unter anderem die Anforderung fur die neue 
Seite. Fur eine im Sinne der vorliegenden Erfindung ordnungs- 
gemafte serverseitige Behandlung solcher Post-Requests ist es 
daher beispielsweise moglich, dass der Server die Identifi- 

10 zierungsdaten der ubermittelten Seite als versteckte, auf 
Seiten des Clients nicht mit angezeigte Eingabef elder bei- 
fugt. Erf indungsgemSft werden also der Seite versteckte Einga- 
bef elder beigefiigt, die bei einer ublichen Darstellung der 
Seite in einem Fenster des Clients nicht mit angezeigt wer- 

15 den. In diesen Eingabef eldern sind von Seiten des Servers be- 
reits vorab die I dent if izierungsdaten hinterlegt worden. Sie 
werden daher vom Client an den Server zurtick ubermittelt, 
wenn der Client einen Post-Request sendet. 

20 Bei Get-Requests hingegen wird vom Client unmittelbar eine 

Linkadresse, in der Regel eine sogenannte URL, an den Server 
zuruck Ubermittelt. Die Linkadresse ist dabei Bestandteil der 
zuvor tibermittelten Seite und wird in dem Fenster, in dem der 
Client die Seite darstellt, als solche mit angezeigt. Selek- 

25 tiert der Benutzer des Clients diese Linkadresse, stellt die 
Linkadresse selbst und unmittelbar eine Anforderung fur eine 
weitere Seite dar. 

Wenn die Seite mindestens eine derartige Adresse ftir eine 
30 weitere Seite enthalt, kann eine im Sinne der vorliegenden 

Erfindung ordnungsgemafie serverseitige Behandlung eines sol- 
chen Get-Requests dadurch erreicht werden, dass der Server 
die Identif izierungsdaten der tibermittelten Seite als der Ad- 
resse zugeordnete Parameter, sogenannte Query-Parameter, bei- 
35 fttgt. 
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Ein Spezialfall einer Reaktion des Servers auf den Erhalt ei- 
ner Anforderung ist ein sogenannter serverseitiger Response- 
Redirect. Ein serverseitiger Response-Redirect liegt vor, 
wenn der Server auf Grund einer an ihn tibermittelten Anforde- 
5 rung nicht die angeforderte Seite an den Client ubermittelt, 
sondern bei Erhalt der weiteren Anforderung zunachst eine 
dritte, vom Client wieder an den Server zuruck zu sendende 
Anforderung an den Client ubermittelt. Erst auf Grund der 
Obermittlung der dritten Anforderung an den Server ubermit- 
10 telt der Server dann die angeforderte Seite. In diesem Fall 
gibt es zwei MSglichkeiten, serverseitig eine im Sinne der 
vorliegenden Erfindung ordnungsgemaBe Behandlung der Anforde- 
rung zu gewahrleisten. 

15 Zum einen ist es moglich, dass der Server die Identifizie- 

rungsdaten der dritten Anforderung als zugeordnete Parameter 
beifiigt. In diesem Fall werden die Identif izierungsdaten der 
Anforderung selbst beigefugt. Alternativ ist es auch moglich, 
dass der Server die Identif izierungsdaten der dritten Anfor- 

20 derung als Anhangseldatei beifiigt, die vom Client nicht der 
dritten Anforderung an den Server zuruck Ubermittelt mit. In 
diesem Fall fiigt der Server die Identif izierungsdaten der 
dritten Anforderung also als sogenanntes Transf ercookie bei. 
Die Identifizierungsdaten sind der Seite dabei wie auch bei 

25 Post-Requests als versteckte Daten beigefugt. Das Programm 

extrahiert die Identifizierungsdaten und fugt sie in die An- 
hangseldatei ein. Weiterhin Ubermittelt der Server zusammen 
mit der Seite, die er auf Grund der dritten Anforderung an 
den Client Ubermittelt, einen L5schbefehl fUr diese Anhang- 

30 seldatei an den Client. 

Es gibt Sprachen, bei denen den vom Server an den Client 
ubermittelten Seiten Programme beigefugt bzw. die Programme 
in diese Seiten eingebettet sein k6nnen. Ein Beispiel einer 
35 solchen Sprache ist JavaScript. In diesem Fall gibt es eine 
weitere Mbglichkeit, zu gewahrleisten, dass die Identifizie- 
rungsdaten zusammen mit der Anforderung vom Client an den 
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Server ubermittelt werden. Denn in diesem Fall ist es m6g- 
lich, dass der Server die Identif izierungsdaten der Seite da- 
durch beifiigt, dass er der Seite ein Programm beifiigt, auf 
Grund dessen der Client einer Anforderung fur eine Seite dann 
5 und nur dann eine die Identif izierungsdaten enthaltende An- 
hangseldatei beifugt, wenn die Anforderung von dieser Ober- 
mittlung der Seite ausgeht. 

In diesem Fall wird also ebenfalls ein sogenanntes Transfer- 
10 cookie erzeugt. Die Erzeugung des Transf ercookies erfolgt 

aber im Gegensatz zum Response-Redirect nicht serverseitig, 
sondern client seitig . 

Der Server kann nicht unmittelbar erkennen, wenn auf Seiten 

15 des Clients eine Duplizierung einer bereits an den Client 
libertragenen Seite erfolgt. Wenn daher der Benutzer des 
Clients eine Seite dupliziert und danach langere Zeit mit nur 
einer der beiden Versionen der duplizierten Seite arbeitet, 
die andere Version der duplizierten Seite aber nicht veran- 

20 dert, bleibt diese andere Version vorerst unverandert erhal- 
ten. Wenn der Benutzer des Clients dann zu einem erheblich 
spateren Zeitpunkt von der anderen, noch unveranderten Versi- 
on der duplizierten Seite eine Anforderung an den Server sen- 
det, uberniramt der Server in diesem Fall die Selektionsdaten, 

25 die der ver&nderten Version der duplizierten Seite zu diesem 
Zeitpunkt zugeordnet sind. Die Selektionsdaten kSnnen zu die- 
sem Zeitpunkt aber bereits erheblich geandert worden sein. 
Die Restaurierung des vom Benutzer eigentlich gewiinschten Zu- 
stands der anderen Version der duplizierten Seite kann fur 

30 den Benutzer daher relativ aufwandig sein. Aus diesem Grund 

ist es von Vorteil, so fruh wie moglich zu erkennen, wenn auf 
Seiten des Clients eine bereits an diesen ubermittelte Seite 
dupliziert wird. 

35 Ein sofortiges Erkennen eines solchen Duplizierens ist da- 
durch moglich, 
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- dass der Server der Seite auch eine Variable mit einem An- 
fangswert und ein vom Client beim Darstellen der Seite in 
einem Fenster auszufuhrendes Programm beifiigt, 

- dass der Client auf Grund des Programms den Wert der Vari- 
able, wenn sie den Anfangswert aufweist, abandert und 

- dass der Client auf Grund des Programms die vorherige An- 
forderung zur Ubermittlung der Seite wiederholt, so dass 
der Client, wenn die Variable nicht den Anfangswert auf- 
weist, die bei der vorherigen Anforderung ubermittelten 
Identifizierungsdaten ein zweites Mai an den Server tiber- 
mittelt . 

Denn dann wiederholt der Client die vorherige Anforderung so- 
fort beim Duplizieren der Seite, so dass der Server die Dup- 
lizierung als solche sofort erkennen kann. Der Server erkennt 
bei dieser Vorgehensweise zwar auch dann (f alschlicherweise) 
eine Duplizierung, wenn der Benutzer des Clients - ohne die 
Seite zu duplizieren - diese nur aktualisiert oder auf eine 
client seitig noch gespeicherte, in diesem Fenster aber nicht 
mehr angezeigte Seite zurtick greift. Dies ist aber unkri- 
tisch, da in diesem Fall auf Seiten des Servers lediglich ein 
Fenster verwaltet wird, das auf Seiten des Clients in der Re- 
alitat gar nicht existent ist. Hingegen kann es nicht gesche- 
hen, dass auf Seiten des Clients ein Fenster dupliziert wird 
und der Server dies nicht erkennt. Die Anforderung kann dabei 
je nach Anwendungsf all in Form eines Post- oder in Form eines 
Get-Requests an den Server ubermittelt werden. Dies gilt auch 
dann, wenn das erstmalige Laden der Seite auf Grund eines 
Post-Requests erfolgte. 

Das erfindungsgemaUe Betriebsverf ahren ist als Computerpro- 
gramm realisiert, das dem Server zugefuhrt wird. Das Compu- 
terprogramm wird dem Server dabei aber einen Datentrager zu- 
geftihrt. Beispiele eines derartigen Datentragers sind eine 
CD-ROM oder eine Streamerkassette . Auf dem Datentrager ist 
das Computerprogramm in (ausschliefilich) maschinenlesbarer 
Form gespeichert. Das Computerprogramm kann auf dem Datentra- 
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ger dabei alternativ in komprimierter oder in unkomprimierter 
Form gespeichert sein. 

Der Datentrager mit dem darauf gespeicherten Computerprogramm 
5 wird in ein Lesegerat eingeftihrt, mittels dessen der Server 
das auf dem Datentrager gespeicherte Computerprogramm lesen 
kann. Er liest daher das Computerprogramm vom Datentrager aus 
und speichert es in einem Massenspeicher ah, beispielsweise 
auf einer Festplatte. Bei Aufruf des Computerprogramms von 
10 der Festplatte (alternativ auch vom Datentrager) ist der Ser- 
ver daher in der Lage, das erf indungsgemafle Betriebsverf ahren 
auszufuhren. 

Weitere Vorteile und Einzelheiten ergeben sich aus der nach- 
15 folgenden Beschreibung eines Ausf iihrungsbeispiels in Verbin- 
dung mit den Zeichnungen. Dabei zeigen 



FIG 1 einen Rechnerverbund, 

FIG 2 ein Ablauf diagramm, 

20 FIG 3 eine Tabelle und 

FIG 4 bis 7 weitere Ablauf diagramme . 



Gemafi FIG 1 ist ein Server 1 ttber eine Rechner-Rechner-Ver- 
bindung 2 mit einem Client 3 datentechnisch verbunden. Die 
25 Rechner-Rechner-Verbindung 2 kann dabei auf verschiedene Art 
ausgebildet sein. In der Regel ist sie jedoch als Internet- 
oder als Intranet-Verbindung ausgebildet. ttber die Rechner- 
Rechner-Verbindung 2 konnen der Server 1 und der Client 3 ge- 
maft einem Web-Protokoll miteinander kommunizieren. 

30 

Der Server 1 weist, wie allgemein (iblich, mehrere Komponenten 
4 bis 8 auf, die fiber einen Bus 9 miteinander verbunden sind. 
Die Komponenten 4 bis 8 umfassen insbesondere einen Prozessor 
4, einen Massenspeicher 5 (typisch eine oder mehrere Fest- 
35 platten) , ein Lesegerat 6, einen Zeitgeber 7 und eine Netz- 
werkkarte 8. 
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In das Lesegerat 6 ist ein Datentrager 10 einfuhrbar, auf dem 
in ausschliefllich maschinenlesbarer Form ein Computerprogramm 
11 gespeichert ist. Dieses Computerprogramm 11 wird von dem 
Datentrager 10 ausgelesen und, wie in FIG 1 gestrichelt ange- 
5 deutet ist, im Massenspeicher 5 hinterlegt. Bei Aufruf des 
Computerprogramms 11 ist der Server 1 daher in der Lage, das 
Computerprogramm 11 auszufuhren. Bei Aufruf des Computerpro- 
gramms 11 ftihrt der Server 1 dabei ein Betriebsverf ahren aus, 
das nachfolgend in Verbindung mit FIG 2 naher beschrieben 
10 wird. 



Gemafi FIG 2 nimmt der Server 1 in einem Schritt SI vom Client 
3 eine Anmeldung und eine erste Anforderung ftir eine Seite 
entgegen. Der Server 1 ermittelt daraufhin in einem Schritt 
15 S2 einen Obermittlungsidentif izierer Obld. Der Obermittlungs- 
identif izierer Obld ist dabei vorzugsweise weltweit einmalig. 
Beispielsweise kann er aus einer Kombination der vom Zeitge- 
ber 7 ausgegebenen Zeit und dem Code der Netzwerkkarte 8 
und/oder des Prozessors 4 bestehen. 

20 

In einem Schritt S3 wird sodann ein Fensteridentif izierer 
Feld gleich dem soeben ermittelten Obermittlungsidentif izie- 
rer Obld gesetzt. Die beiden Identif izierer Obld, Feld werden 
sodann - siehe erg^nzend FIG 3 - in die erste Zeile einer Ta- 
25 belle 12 eingetragen. Gem^JS FIG 3 k6nnen dabei jeder Zeile 
der Tabelle 12 aulier den beiden Identif izierern Obld, Feld 
auch noch Selektionsdaten SD zugeordnet werden. Auf die Be- 
deutung der Selektionsdaten SD wird nachstehend noch einge- 
gangen werden. 

30 

In einem Schritt S5 ftigt der Server 1 der angef orderten Seite 
die Identif izierungsdaten Feld, Obld bei. Die Beiftigung er- 
folgt dabei derart, dass die Identif izierungsdaten Feld, Obld 
bei einer weiteren Anforderung ftir eine Seite vom Client 3 
35 dann und nur dann an den Server 1 zurtick tibermittelt werden, 
wenn die Anforderung auf Seiten des Clients 3 von der Ober- 
mittlung dieser Seite ausgeht. 
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Gemafc einem Schritt S6 fugt der Server 1 weiterhin der ange- 
forderten Seite eine Variable und ein Programm bei. Die Vari- 
abel weist einen Anfangswert auf . Das Programm ist derart 
ausgestaltet, dass es bei einem clientseitigen Kopieren der 
5 ubertragenen Seite eine Neuanf orderung der bisherigen Seite 
auslost. Hierauf wird spater noch naher eingegangen werderi; 
Der Schritt S6 ist dabei nur optional und daher in FIG 2 nur 
gestrichelt dargestellt. In einem Schritt S7 ubermittelt der 
Server 1 sodann die angeforderte Seite einschlieiilich der 
10 dieser Seite beigefugten Inf ormationen an den Client 3. Bei 

den beigeftigten Inf ormationen handelt es sich insbesondere urn 
die beiden beigefugten Identif izierer Obld, Feld, deren Er- 
ganzungen sowie die Variable und das Programm. 

15 In einem Schritt S8 nimmt der Server 1 vom Client 3 eine wei- 
tere Eingabe entgegen. Der Server 1 uberpruft daraufhin zu- 
nachst in einem Schritt S9, ob der Client 3 sich abgemeldet 
hat. Wenn dies der Fall ist, 16scht er in einem Schritt S10 
die Tabelle 12 und beendet die Ausfuhrung des Verfahrens. 

20 

Wenn die Eingabe des Schritt es S8 keine Abmeldung war, war 
sie eine neue Anf orderung. In diesem Fall extrahiert der Ser- 
ver 1 aus der ubermittelten Anforderung die zurtick ubermit- 
telten Identif izierer Obld, Feld sowie die Selektionsdaten 
25 SD. 

In einem Schritt S12 uberprtaft der Server 1 sodann, ob der 
zuruck tibermittelte Obermittlungsidentif izierer Ubld mit dem 
Obermittlungsidentifizierer Obld ubereinstimmt, der in der 

30 Tabelle 12 dem zurUck ubermittelten Fensteridentif izierer 
Feld zugeordnet ist. Der besseren Obersichtlichkeit halber 
ist der Schritt S12 in FIG 2 dabei in zwei Teilschritte S12a, 
S12b aufgeteilt. Im Teilschritt S12a wird eine logische Vari- 
able entsprechend der vorzunehmenden Prufung belegt, im Teil- 

35 schritt S12b die logische Variable abgefragt. 
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Wenn im Schritt S12 eine Obereinstimmung ermittelt wurde, 
geht die vom Client 3 ubermittelte Anforderung von einem ser- 
verseitig bereits qrfassten und verwalteten Fenster des 
Clients 3 aus. In diesem Fall wird in einem Schritt S13 ana- 
log zum Schritt S2 ein neuer Obermittlungsidentif izierer Obld 
ermittelt und in der Tabelle 12 in der Zeile abgespeichert, 
in der auch der zurttck tibermittelte Fensteridentif izierer 
Feld abgespeichert ist. Der Server 1 speichert also den neu 
ermittelten Obermittlungsidentif izierer Obld anstelle des zu- 
rttck ttbermittelten Obermittlungsidentif izierer Obld in der 
Tabelle 12 ab. 

Wenn im Schritt S12 hingegen keine Obereinstimmung festge- 
stellt wurde f wird ein Schritt S14 ausgeftthrt. Im Schritt S14 
wird ebenfalls der Obermittlungsidentif izierer Obld analog 
zur Vorgehensweise von Schritt S2 neu ermittelt. Sodann wird 
aber der Fensteridentif izierer Feld analog zum Schritt S3 
gleich dem soeben neu ermittelten Obermittlungsidentif izierer 
Obld gesetzt. Beide Identif izierer Feld, Obld werden vom Ser- 
ver 1 in eine neue Zeile der Tabelle 12 eingetragen. Ferner 
werden im Rahmen des Schrittes S14 noch die Selektionsdaten 
SD, die dem zurttck ttbermittelten Fensteridentif izierer Feld 
zugeordnet sind, in die nunmehr neu belegte Zeile der Tabelle 
12 kopiert. 

Falls der Server 1 neue Selektionsdaten SD erhalten hat, an- 
dert er ferner in einem Schritt S15 die Selektionsdaten SD 
ab, die dem aktuellen Fensteridentif izierer Feld zugeordnet 
sind. Je nach dem, ob auf Grund der Prttfung im Schritt S12 
der Schritt S13 oder der Schritt S14 durchlaufen wurde, han- 
delt es sich dabei um den zurttck ttbermittelten Fensteridenti- 
fizierer Feld oder um den neu ermittelten Fensteridentif izie- 
rer Feld. 

In einem Schritt SI 6 ttberprttft der Server 1 als nachstes, ob 
er die angeforderte Seite direkt ttbermitteln kann oder ob er 
ein sogenanntes Response-Redirect durchftthren muss. Wenn er 
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ein Response-Redirect durchfiihren muss, ftihrt er einen 
Schritt S17 aus, in dem er eine neue Adresse, in der Regel 
eine URL-Adresse zuzuglich des aktuellen Fensteridentif izie- 
rers Feld und des aktuellen Obermittlungsidentif izierers Obld 
5 an den Client 3 tibermittelt . Sodann springt er zum Schritt S8 
zurttck. 

Anderenfalls ermittelt der Server 1 anhand der Selektionsda- 
ten, die dem aktuellen Fensteridentif izierer Feld und dem ak- 
10 tuellen Obermittlungsidentif izierer Obld in der Tabelle 12 
zugeordnet sind, welche Seite an den Client 3 iibermittelt 
werden soil. Alternativ oder erganzend kann auch der Inhalt 
der Seite modifiziert werden. Sodann springt der Server 1 zum 
Schritt S5 zuruck. 

15 

FIG 4 zeigt eine erste Moglichkeit, die Identif izierungsdaten 
Obld, Feld der zu tibermittelnden Seite beizufligen. Gemaft FIG 
4 fugt der Server 1 der Seite die Identif izierer Obld, Feld 
in einem Schritt S19 zunachst als versteckte Eingabef elder 
20 bei. Dadurch ergibt sich die Wirkung, dass die Identif izierer 
Obld und Feld bei jedem Post-Request des Clients 3, der von 
dieser Seite ausgeht, vom Client 3 an den Server 1 ubermit- 
telt werden. 

25 In einem Schritt S20 tiberpruft der Server 1 sodann, ob die zu 
ubermittelnde Seite eine URL-Adresse enthalt, der die Identi- 
fizierer Obld und Feld noch nicht als Query-Parameter beige- 
fugt wurden. Wenn dies der Fall ist, ftihrt der Server 1 einen 
Schritt S21 aus, in dem er dieser Adresse die Identif izierer 

30 Obld und Feld als Query-Parameter beifugt. Vom Schritt S21 

geht der Server dann zum Schritt S20 zurtick. Der Schritt S20 
ist dabei in FIG 4 - analog zum Schritt S12 von FIG 2 - in 
zwei Teilschritte unterteilt. 

35 FIG 5 zeigt eine weitere Moglichkeit, die Identif izierungsda- 
ten Obld, Feld der Seite beizufttgen. Gemali FIG 5 fugt der 
Server 1 der Seite die Identif izierer Obld und Feld als ver- 
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steckte Daten bei. Dabei kann es sich - analog zum Schritt 
S19 von FIG 4 - urn versteckte Eingabef elder handeln. Dies ist 
aber nicht zwingend erforderlich. Sodann ftigt der Server 1 
der Seite ein Programm bei, das bei einer Anforderung des 
Clients 3, die von dieser Seite ausgeht, ausgefuhrt wird. Auf 
Grund des Programms extrahiert dann der Client 3 aus dieser 
Seite die Identif izierungsdaten Obld, Feld und bindet sie in 
ein von ihm zu kreierendes Cookie ein. Das Cookie sendet der 
Client 3 zusammen mit der Anforderung an den Server 1. 

FIG 6 zeigt die Moglichkeiten, die bestehen, urn den Schritt 
S17 von FIG 2, in dem die Identif izierer Feld und Obld der zu 
ubermittelnden URL beigefiigt werden, zu implementieren. Gemafi 
FIG 6 ist es mdglich, den Schritt S17 derart auszugestalten, 
dass die Identif izierer Obld und Feld - analog zum Schritt 
S21 von FIG 4 - der URL-Adresse als Query-Parameter beigeftigt 
werden. Alternativ ist es mSglich, dass der Server 1 im 
Schritt S17 der URL-Adresse eine Anhangseldatei (Cookie) bei- 
ftigt, welche die Identif izierer Obld, Feld enthalt. In diesem 
letzteren Fall sollten die im Schritt S7 (siehe FIG 2) der 
angeforderten Seite beigefugten Inf ormationen an den Client 3 
einen Loschbefehl enthalten, auf Grund dessen diese Anhang- 
seldatei auf Seiten des Clients 3 sofort wieder gel6scht 
wird. 

Von den in FIG 6 dargestellten Schritten S17 wird stets nur 
einer ausgeftihrt. Die beiden Schritte S17 sind daher in FIG 6 
gestrichelt dargestellt. 

FIG 7 zeigt nun der Vollstandigkeit halber das Verfahren, das 
der Client 3 auf Grund des Programms ausfuhrt, das vom Server 
1 im Rahmen des Schrittes S6 (siehe FIG 2) der angeforderten 
Seite beigeftigt wird. Das Programm wird dabei vom Client 3 
stets ausgefuhrt, wenn die Seite von ihm in einem Fenster 
dargestellt wird. Das Programm wird also sowohl dann ausge- 
fuhrt, wenn der Client 3 die Seite erstmals erhalt, als auch 
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dann, wenn der Client 3 die Seite beispielsweise mit "Steue- 
rung N" dupliziert. 

Gemafi FIG 7 extrahiert der Client 3 zunachst aus der Seite 
5 die tibermittelte Variable. In einem Schritt S25 uberpruft er 
dann, ob die Variable noch ihren Anfangswert hat. Wenn dies 
der Fall ist, setzt er die Variable in einem Schritt S26 auf 
ihren Endwert. Der Endwert muss dabei selbstverstandlich vom 
Anfangswert verschieden sein. Ansonsten kann er beliebig ge- 

10 wahlt sein. Wenn die Prufung im Schritt S25 keine Oberein- 
stimmung ergeben hat r fiihrt der Client 3 einen Schritt S27 
aus, in dem er die vorherige Anforderung wiederholt. Die Wie- 
derholung der Anforderung bewirkt dabei insbesondere, dass 
die bereits an den Server 1 zuriick libermittelten Identifizie- 

15 rungsdaten Obld, Feld ein zweites Mai an den Server 1 uber- 
mittelt werden. Dadurch ist dann der Server 1 sofort in der 
Lage, zu erkennen, dass clientseitig ein neues Fenster geoff- 
net wurde. 



20 



Mittels des erf indungsgemaiien Betriebsverf ahrens ist es somit 
auf einfache Weise moglich, dass der Server 1 individuell 
mehrere Fenster des Clients 3 verwaltet. 
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Patentansprtiche 

1. Betriebsverfahren fur einen Server (1), der mit einem 
Client (3) kommuniziert, 
5 - wobei der Server (1) , wenn ihm vom Client (3) eine Anforde- 

rung fur eine Seite iibermittelt wird, die angeforderte Sei- 

te an den Client (3) abermittelt, 

- wobei der Server (1) der Seite Identif izierungsdaten (Obld, 
Feld) derart beifiigt, dass die Identif izierungsdaten (Obld, 

10 Feld) bei einer weiteren Anforderung ftir eine Seite vom 

Client (3) dann und nur dann an den Server (1) zuruck aber- 
mittelt werden, wenn die Anforderung auf Seiten des Clients 
(3) von dieser Obermittlung der Seite ausgeht, 

- wobei die Identif izierungsdaten (Obld, Feld) zumindest ei- 
15 nen ftir die Obermittlung der Seite spezifischen Obermitt- 

lungsidentifizierer (Obld) umfassen, 

- wobei der Server (1) die von ihm iibermittelten Identif izie- 
rungsdaten (Obld) abspeichert, 

- wobei der Server (1) bei Erhalt der weiteren Anforderung 
20 den von ihm neu iibermittelten Obermittlungsidentif izierer 

(Obld) anstelle des zuruck iibermittelten Obermittlungsiden- 
tif izierer s (Obld) abspeichert, wenn der zuriick ubermittel- 
te Obermittlungsidentifizierer (Obld) mit einem abspeicher- 
ten Obermittlungsidentifizierer (Obld) ubereinstimmt, und 

25 - wobei der Server (1) bei Erhalt der weiteren Anforderung 
den von ihm neu iibermittelten Obermittlungsidentifizierer 
(Obld) zusatzlich zum zuriick iibermittelten Obermittlungsi- 
dentifizierer (Obld) abspeichert, wenn der zuriick iibermit- 
telte Obermittlungsidentifizierer (Obld) mit keinem zuvor 

30 abspeicherten Obermittlungsidentifizierer (Obld) iiberein- 
stiramt . 

2. Betriebsverfahren nach Anspruch 1, 
dadurch gekennzeichnet, 
35 dass den Identif izierungsdaten (Obld, Feld) Selektionsdaten 
(SD) zugeordnet sind und dass im Falle der Obereinstimmung 
des zuriick iibermittelten Obermittlungsidentif izierers (Obld) 
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mit einem der abgespeicherten Obermittlungsidentif izierer 
(Obld) die vom Server (1) auf Grund der weiteren Anforderung 
neu an den Client (3) iibermittelte Seite von den dem uberein- 
stimmenden Obermittlungsidentif izierer (Obld) zugeordneten 
Selektionsdaten (SD) abhSngt. 

3. Betriebsverfahren nach Anspruch 2, 
dadurch gekennzeichnet, 

dass im Falle der Obereinstimmung des zuruck abermittelten 
Obermittlungsidentifizierers (Obld) mit keinem der abgespei- 
cherten Obermittlungsidentif izierer (Obld) die vom Server (1) 
auf Grund der weiteren Anforderung neu an den Client (3) 
iibermittelte Seite von den einem der abgespeicherten Ober- 
mittlungsidentif izierer (Obld) zugeordneten Selektionsdaten 
(SD) abhangt und dass der Server (1) diese Selektionsdaten 
(SD) dem zusatzlich abgespeicherten Obermittlungsidentif izie- 
rer (Obld) zuordnet. 

4. Betriebsverfahren nach Anspruch 1, 2 oder 3, 
dadurch gekennzeichnet, 

- dass die Identif izierungsdaten (Obld, Feld) auch einen 
Fensteridentif izierer (Feld) umfassen, 

- dass der Server (1) im Falle der Obereinstimmung des zuruck 
abermittelten Obermittlungsidentif izierers (Obld) mit einem 
der abgespeicherten Obermittlungsidentif izierer (Obld) den 
Fensteridentif izierer (Feld) des tibereinstimmenden Ober- 
mittlungsidentif izierers (Obld) beibehalt und 

- dass der Server im Falle der Obereinstimmung des zurtick 
abermittelten Obermittlungsidentif izierers (Obld) mit kei- 
nem der abgespeicherten Obermittlungsidentif izierer (Obld) 
dem zusatzlich abspeicherten Obermittlungsidentif izierer 
(Obld) einen neuen Fensteridentif izierer (Feld) zuordnet. 

5. Betriebsverfahren nach Anspruch 3 und 4, 
dadurch gekennzeichnet, 

dass im Falle der Obereinstimmung des zurack abermittelten 
Obermittlungsidentif izierers (Obld) mit keinem der abgespei- 
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cherten Obermittlungsidentif izierer (Obld) die vom Server (1) 
auf Grund einer weiteren Anforderung neu an den Client (3) 
ubermittelte Seite von den Selektionsdaten (SD) abhangt, die 
demjenigen der abgespeicherten Obermittlungsidentif izierer 
(Obld) zugeordnet sind, dessen Fensteridentif izierer (Feld) 
mit dem zuruck ubermittelten Fensteridentif izierer (Feld) 
tibereinstimmt . 

6. Betriebsverfahren nach einem der obigen Ansprtiche, 
dadurch gekennzeichnet, 

dass der Server (1) die Identif izierungsdaten (Ubld, Feld) 
der ubermittelten Seite als versteckte, auf Seiten des 
Clients (3) nicht mit angezeigte Eingabef elder beiftigt. 

7. Betriebsverfahren nach einem der obigen Ansprtiche, 
dadurch gekennzeichnet, 

dass die Seite mindestens eine Adresse fur eine weitere Seite 
enthalt und dass der Server (1) die Identif izierungsdaten 
(Obld, Feld) der Ubermittelten Seite als der Adresse zugeord- 
nete Parameter beiftigt. 

8. Betriebsverfahren nach einem der obigen Ansprtiche, 
dadurch gekennzeichnet, 

dass der Server (1) bei Erhalt der weiteren Anforderung zu- 
nSchst eine dritte, vom Client (3) wieder an den Server (1) 
zurtick zu sendende Anforderung an den Client (3) tibermittelt 
und dass der Server (1) die Identif izierungsdaten (Obld, 
Feld) der dritten Anforderung als zugeordnete Parameter bei- 
ftigt. 

9. Betriebsverfahren nach einem der obigen Ansprtiche, 
dadurch gekennzeichnet, 

dass der Server (1) bei Erhalt der weiteren Anforderung zu- 
nachst eine dritte, vom Client (3) wieder an den Server (1) 
zuruck zu sendende Anforderung an den Client (3) ubermittelt, 
dass der Server (1) die Identif izierungsdaten (0bld f Feld) 
der dritten Anforderung als Anhangseldatei beifugt, die vom 



WO 2005/038662 



PCT/EP2004/011489 



21 

Client (3) mit der dritten Anforderung an den Server (1) zu- 
rtick Ubermittelt wird, und dass der Server (1) zusammen mit 
der auf Grund der dritten Anforderung an den Client (3) tiber- 
mittelten Seite einen Loschbefehl far diese Anhangseldatei an 
5 den Client (3) ubermittelt. 

10. Betriebsverfahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

dass der Server (1) die Identif izierungsdaten (Ubld, Feld). 
10 der Seite dadurch beifugt, dass er der Seite ein Programm 
beifiigt, auf Grund dessen der Client (3) einer Anforderung 
ftir eine Seite dann und nur dann eine die Identif izierungsda- 
ten (Obld, Feld) enthaltende Anhangseldatei beifiigt, wenn die 
Anforderung von dieser Obermittlung der Seite ausgeht. 

15 

11. Betriebsverfahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

- dass der Server (1) der Seite auch eine Variable mit einem 
Anfangswert und ein vom Client (3) beim Darstellen der Sei- 

20 te in einem Fenster auszuf ahrendes Programm beifugt, 

- dass der Client (3) auf Grund des Programms den Wert der 
Variable, wenn sie den Anfangswert aufweist r abSndert und 

- dass der Client (3) auf Grund des Programms die vorherige 
Anforderung zur Obermittlung der Seite wiederholt, so dass 

25 der Client (3), wenn die Variable nicht den Anfangswert 

aufweist, die bei der vorherigen Anforderung ttbermittelten 
Identif izierungsdaten (Obld, Feld) ein zweites Mai an den 
Server (1) ubermittelt. 

30 12. Datentr^ger mit einem auf dem Datentrfiger gespeicherten 
Computerprogramm (11) zur Durchfiihrung eines Betriebsverf ah~ 
rens nach einem der obigen Anspriiche. 

13. Server mit einem Massenspeicher (5), in dem ein Computer- 
35 programm (11) hinterlegt ist, so dass bei Aufruf des Compu- 
terprogramms (11) von dem Server ein Betriebsverfahren nach 
einem der Anspriiche 1 bis 11 ausftihrbar ist. 
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FIG 5 
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